Mobile mapping applications, e.g., mapping applications for execution on mobile devices such as global positioning system (GPS)-based devices, are often executed on computer-based platforms having a slower central processing unit (CPU) and limited memory in comparison to desktop computer-based platforms. Upfront knowledge of mobile mapping application resource requirements, e.g., CPU speed, memory space, etc., enables better use of the limited resources available on the computer-based platforms, improves performance of the application and provides an improved user experience during interaction with the application.
In mobile mapping applications, many spatial operations, e.g., map display, nearest search and street routing, depend on map density. Map density refers to the amount of information and/or features displayed on a given area of a displayed map. For example, it is not desirable to have too crowded map views which reduce screen readability and increase the time to update the view. At the same time, it is not desirable to have map views with very few features and which do not provide enough navigation information. The problem can be critical for mobile devices having small screens.
The map display detail level, i.e., the amount of features displayed, at a given scale is defined either in the application software or the map database. Users may be provided with a mechanism to manually adjust the map display detail level. In such situations, the setting is constant everywhere in a given map. In reality, the density of a given feature type is not evenly distributed around the world, e.g., there are many more roads per square mile in urban areas than in rural areas. The non-uniformity of feature density increases map developers difficulty in designing map views which work well both in urban areas and rural areas.
Prior approaches predefine at the time of map creation which class of features is displayed at different scales. Because the class of features is predefined for the entire map, by its nature it has to be an average and may be too dense or too sparse for some regions of the map. To adjust these possible mismatches of density, the user is provided with a user interface (UI) that allows the user to change which class of features is displayed at a particular level. Therefore, when the user is dissatisfied with the feature density displayed on the map at a particular location at a particular zoom level, the user can manipulate the UI and change the display level explicitly to be more or less dense.
The prior approach is extremely cumbersome for users especially if a mapping device is used while driving, biking, or any other similar activity when the user's hands and attention may be occupied.
Street routing algorithms also suffer from a non-uniformity of feature density. Street routing may be based on a type of greedy algorithm in which roads are divided into several function classes depending on the importance of the roads, e.g., surface roads, highways, etc. Roads in a given function class and all higher level function classes comprise a connected road network. In order to quickly find a street route between two far away points, a route search engine needs to only examine important roads, e.g., freeways, as soon as possible. In order to maintain route quality, such jumps from local streets to major roads such as highways and freeways have to meet some criteria. Prior approaches predefine the criteria constant everywhere in a given map thereby making the routing algorithm impossible to generate street routes with optimal quality and search time in both urban and rural areas.
In another case, personal navigation devices usually have a nearest (proximity) search function, which allow users to find specific types of objects near a reference point (e.g., the current position). Feature density varies by location and feature type. If a predefined search radius is used, the nearest search function may yield no result, too many results, or take too much time. Even if the search radius is adjusted based on search results, each search iteration can take significant time.